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Disclaimer 


■  Concepts  and  products  are  based  on  results  from  MIP  working  parties 

Model-Driven  Architecture  &  MDA  Evaluation 

Future  Architecture 

MIP  System  Architecture  Design 

■  with  contributions  from  many  different  people/institutions,  e.g. 

Institute  for  Defense  Analyses  (IDA) 

Fraunhofer  FKIE 


■  MIP  has  not  yet  taken  any  formal  decision  on  the  future  of  the  JC3IEDM 
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Introduction 
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Multilateral  Interoperability  Programme 


“The  aim  of  the  Multilateral  Interoperability  Programme  (MIP)  is  to  achieve  international 
interoperability  of  Command  and  Control  Information  Systems  (C2IS)  at  all  levels  from  corps  to 
battalion,  or  lowest  appropriate  level,  in  order  to  support  multinational  (including  NATO), 
combined  and  joint  operations  and  the  advancement  of  digitization  in  the  international  arena." 
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JC3IEDM 


■  Joint  Consultation,  Command,  and  Control 
Information  Exchange  Data  Model 

■  NATO  ratification  as  STAN  AG  5525 

■  Latest  version:  JC3IEDM  3.0.2 

■  Plans  &  Orders,  ATO,  MMW,  CBRN,  ... 

■  Complex  data  model  based  on 
generic  core  concepts 

■  Entity  relationship  model 

■  Semantic  definitions 

Business  Rules 
Free-text  documentation 
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Configuration  Management 
of  the  JC3IEDM 
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Motivation 


■  JC3IEDM  has  been  transformed  from  a  small,  generic  hub  into  a  comprehensive 
data  model 

■  LC2IEDM  2.2  (MIP  Baseline  1):  149  entities 
JC3IEDM  3.0.2  (MIP  Baseline  3):  273  entities 

■  Growing  size  and  complexity  results  in  configuration  management  challenges 

■  Tracking  and  applying  changes  is  laborious 

■  Entity-Relationship  model  in  IDEF1X  is  platform-specific 

Database  concepts,  e.g.,  key  attributes,  discriminator  codes  for  sub-typing 
Not  perfectly  suited  to  other  application  areas 
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Consistency  of  Different  Products 


FEATURE-TYPE 


CONTROL-FEATURE-TYPE  GEOGRAPHIC-FEATURE-TYPE 

f - n - — — - \  c - ~  ■ — : — : - rr^rr~ 


r  A 

control-feature-type-id  (FK) 

geographic-feature-type-id  (FK) 

control-feature-type-category-code 

geographic-feature-type-category-code 

geographic-feature-type-subcategory-code 

v _ _ _ y 

,  control-feature-type-category-code 


ROUTE-TYPE 


Logical/physical  data  model 


Metadata  (MIRD) 


G1 .3.1  Rule  for  minefield-destruction-datetime 

For  the  instances  where  the  MINEFIELD  is  a  MINEFIELD- 
LAND,  then  the  minefield-destruction-datetime  is  filled  only 
where  minefield-land-persistence-code  is  “Remote 
activated  destruction”  or  “Timed  automatic  destruction”. 


Business  Rules 


Table  42.  Examples  of  EXECUTIVE-MILITARY-ORGANISATION-TYPE 

(a)  ORGANISATION-TYPE _ 
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on-type-id 

'-category -code 
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Note:  *  =  "organisation-type” 
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An  ABSOLUTE-POINT  that  has  its  position  specified  in  a 
three-dimensional  Earth-centred  Cartesian  system. 
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An  ABSOLUTE-POINTthat  has  its  position  specified  with 
respect  to  the  sixfeoe  of  the  World  Geodetic  System  1984 
(WGS84)  ellipsoid. 
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Documentation 
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Platform-Independent  Model  (PIM) 


■  Platform-independent  model 

Remove  platform-specific  elements 

Improved  comprehensiveness 

Use  generators  to  derive  platform-specific  models 

■  Unified  Modeling  Language  (UML) 

Great  acceptance  among  software  developers 
Excellent  tool  support 

Recommended  by  NATO  Architecture  Framework  (NAF) 
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Model-Driven  Architecture  (MDA) 


Jb 


JC3IEDM 

(Platform-independent 

model  -  PIM) 


Generators 


Exchange  Formats 

Documentation 

Database  Schemas 

Software  Code 

(XSD,  RDFS,  OWL,  ... 

) 

(HTML,  Word,  ...) 

(SQL) 

(Java,  C++,  .NET,  ...) 

Platform-specific  models  (PSMs) 
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Formalization  of  Business  Rules 


■  Object  Constraint  Language  (OCL) 

Rules  can  be  validated  against  the  JC3IEDM  (statically) 

Rules  can  be  evaluated  by  a  MIP  gateway/C2IS  (dynamically  at  run-time) 


/*  G  1.4.1  Part  b  7 
context  Objectltem 

inv: 

(self.ocllsKindOf(GeographicFeature)  or 
self.ocllsKindOf(MeteorologicFeature)) 

implies 

self.has_hostility_status->size()  =  0 
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Documentation  with  DocDB 


Model  Driven  Architecture  Tools  and  Techniques 


Multilateral  Interoperability  Programme _ 

Home  |  BL3  Documents  |  BLF  Documents  |  Maintenance  |  Downloads  |  Wiki  |  Discussion  |  Links  | 

7.  STATUS  OF  IDENTIFIABLE  OBJECTS 


IDA 


10.  CAPABILITIES  OF 


OBJECTS  AND  TYPES 


This  chapter  deals  with  a  general  requirement  of  specifying  the  status  of  items  at  a  given  time  (past,  present,  or  predicted).  The  main  topics  include: 

a.  Classifying  the  hostility'  state  of  an  Objectltem, 

b.  Assigning  categories  to  Objectltems  to  capture  administrative,  medical,  physical,  and  procedural  states  or  conditions. 

Section  7.1  provides  the  specifications  for  hostility  status;  Section  7.2  is  a  general  introduction  to  ObjectltemStatus  and  its  subtypes;  Section  7.3  specifies  the  details  for 
recording  the  status  of  all  Objectltems  with  the  exception  of  MedicalFacilityStatus  that  is  the  subject  of  Section  7  4.  The  chapter  ends  with  Section  7.5  that  provides  a  cross- 
reference  to  the  applicable  business  rules  that  are  listed  in  Annex  G2. 

7.1  ObjectltemHostilityStatus 

7.1.1  Most  objects  of  the  battlefield  can  be  characterised  as  friend  or  enemy.  This  information  is  not  inherent  to  the  specific  object.  The  hostility'  status  of  an  object  is  a 
classification  that  a  specific  organisation  gives  to  this  object.  It  means  that  a  specific  object  may  have  different  hostility'  status  given  by  different  organisations,  and  that  the 
hostility'  status  may  vary'  with  time.  The  known  or  perceived  friendly  or  aggressive  intentions  of  an  object  are  recorded  in  the  entity'  ObjectltemHostilityStatus  w'hose  structure 
of  is  illustrated  in  the  figure  below'. 


«supercls» 
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«text» 

+  nameText 


17 
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+has_hostility_status 


«cls» 

ObjectltemHostilityStatus 


«code» 

+  code 


JC3IEDM  documentation  in 
structured  format  (annotations) 

Supports  consistency  checks 
against  the  UML  PIM 


Figure  64.  ObjectltemHostility  Status 

7.1.2  ObjectltemHostilityStatus  is  defined  as  “A  record  of  the  perceived  hostility'  classification  of  a  specific  Objectltem."  Its  attributes  are: 

a.  obiectltemld — The  unique  value,  or  set  of  characters,  assigned  to  represent  a  specific  Objectltem  and  to  distinguish  it  from  all  other  Objectltems.  It  is  a 
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Improved  Change  Management 


Problem: 

■  Change  Proposals  (CPs)  are  provided  as  semi-structured  Word  documents 

■  Approved  CPs  must  be  applied  manually  to  the  JC3IEDM  by  a  core  group  of  experts 

■  National/COI-specific  extensions  are  inadequately  tracked 


Solution:  Formal  technical  CPs 

■  Atomic  operations  (e.g.,  add  new  attribute,  modify  domain  value) 

■  Meta  information  inspired  by  NATO  Discovery  Metadata  Specification  (NDMS) 

■  CPs  are  tracked  in  the  model  itself 
4  Early  validation  of  CPs 

Automatic  processing  of  CPs 
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PIM  Restructuring 
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Motivation 


■  Resolve  well-known  problems/workarounds,  e.g., 

Deletion/update  of  information 
Grouping  of  information 
Archiving 

■  Make  the  model  independent  from  a  specific  exchange  mechanism 

■  Generalize  existing  concepts 

■  Provide  a  sound  basis  for  the  definition  of  capability-specific  sub-models 
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JC3IEDM  3.0.2  -  Metadata  &  Information  Groups 
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Logical  Layers  in  the  Data  Model 


Core  Modeling  Layer 

(Information  &  Information  Group  Concepts) 


Metadata  Layer 


Staff  Objects  Layer 
(Grouping  and  Manipulating  Objects) 


Battlefield  Objects  Layer 
(Granular  Objects) 
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Core  Modelling  Layer 
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Metadata  Layer 


class  Layer  Metadata 
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Staff  Objects  Layer 


class  Layer  Staff  Objects 


information^ PerGrouP  0. 
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+  nameText:  String 
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Battlefield  Objects  Layer 


class  Layer  Battlefield  Objects  i 
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■  Only  Objectlnformation  are 
linked  to  an  information  group 

■  Value  objects  such  as  Location 
and  Status  are  linked  implicitly 

■  ReportingData  is  no  longer 
abused  for  grouping 
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Modularization 
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Motivation 


■  Faster  response  to  user  requirements 

From  operational  requirement  to  the  field 

■  Keep  existing  information  exchange  services  stable 

4  Incremental  delivery  of  independent  capabilities 
*  Modular  interoperability  solution 

■  Complete  specification  of  information  exchange  capabilities 

Data  modeling  is  considered  part  of  the  overall  modeling  process! 
NATO  Architecture  Framework 

■  Operational  Views 

■  Service  Views 
System  View 
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Business  Models 
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Data  Management  Challenges 


■  New  business  models  may 
require  extensions/changes  to 
the  JC3IEDM 

■  Changes  to  the  JC3IEDM  may 
have  impact  on  existing 
business  models 

*Need  for  impact  analysis 
(configuration  management, 
versioning,  ...) 

■  Proposed  solution:  Define 
business  models  by 
transformation  scripts 
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Interoperability  Based  on  Monolithic  Model 


Operational  Requirement 
/  Feedback 


Data  Modellers 


NATION  A 

NATIONAL 

C2IS  (A) 


ODB 
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JC3IEDM 


INTERNATIONAL 

MIP  SOLUTION 

(Lingua  Franca) 


JC3IEDM1 


Specifications 

SOPs 

Documents 

(MIP) 


JC3IEDM1 


NATION  B 


NATIONAL 

C2IS  (B) 


ODB 
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Interoperability  Based  on  Business  Models 


Operational  Requirement 
/  Feedback 


BM1 


Data  Modellers  CP 
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Summary  (1) 


■  Improved  configuration  management 

UML  platform-independent  model  of  the  JC3IEDM  3.0.2 
Available  in  Sparx  Enterprise  Architect  format 
Semantically  equivalent  to  ER  model 
PSM  generators  available  for  XSD,  OWL,  SQL,  Java 
CPProcessor  for  automatic  processing  of  change  proposals 
Unofficial  web  site:  http://mda.cloudexp.com/ 

■  PIM  Restructuring 

Concept  proposal  addresses  issues,  constraints,  and  workarounds 
Semantics  of  the  JC3IEDM  operational  concepts  is  basically  maintained 
Technical  CPs  currently  under  development 
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Summary  (2) 


■  Modularization 

Supports  incremental  delivery  of  new  capabilities/services 
Smaller,  but  clearer  specified  capabilities 
Data  modelling  is  not  an  isolated  task 

Clear  traceability  to  individual  capabilities/services 
No  data  modelling  for  the  sake  of  it! 

JC3IEDM  is  used  as  a  semantic  reference 

■  Potential  collaboration  between  MIP  and  C-BML  community 

Provide  feedback  on  operational  &  structural  aspects 
Identify  relevant  subview  of  the  JC3IEDM 
Harmonization  of  lERs  by  NATO  APP-15? 
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Thank  you 
for  your  attention! 
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